|
__NOTOC__ A type-in program, type-in game or just type-in, is a computer program listing printed in a computer magazine or book, meant to be typed in on the computer's keyboard by the reader in order to run the program. Type-ins were very common in the early home computer era of the late 1970s and early 1980s because of the period's lack of inexpensive portable storage media, the low penetration of modems and bulletin board systems, and the relatively short maximum length for a program's code on a home computer with a main memory of a few tens of kilobytes. Type-ins were often seen as useful for learning programming, allowing users to begin their programming efforts by porting a program written for one system for use on another. == Description == Here is an example of a type-in: Listing 1. 10 PRINT "HELLO, WORLD!" 20 GOTO 10 To use this type-in, a reader would take a printed copy of the program listing, such as from a magazine or book, sit down at a computer, and manually enter the two lines of code ("Listing 1." is a heading and is not part of the code). Computers of this era automatically booted into a programming environment – even the commands to load and run a prepackaged program were really programming commands executed in direct mode. After typing the program in, the user would be able to run it and also to save it to disk or cassette for future use. Users were often cautioned to save the program before running it, as errors could result in a crash requiring a reboot, which would render the program irretrievable unless it had been saved. The simple program displayed above is a trivial example - many type-ins were fully functional games or application software, sometimes rivaling commercial packages. Type-ins were usually written in BASIC or a combination of a BASIC loader and machine language. In the latter case, the opcodes and operands of the machine language part were often simply given as DATA statements within the BASIC program, and were loaded using a POKE loop, since few users had access to an assembler. In some cases, a special program for entering machine language numerically was provided. Programs with a machine language component sometimes included assembly language listings for users who had assemblers and who were interested in the internal workings of the program. The downside of type-ins was labor. The work required to enter a medium-sized type-in was on the order of hours. If the resulting program turned out not to be to the user's taste, it was quite possible that the user spent more time keying in the program than using it. Additionally, type-ins were error-prone, both for users and for the magazines. This was especially true of the machine language parts of BASIC programs, which were nothing but line after line of DATA statements. In some cases where the version of ASCII used on the type of computer the program was published for included printable characters for each value from 0–255, the code could have been printed using strings that contained the glyphs that the values mapped to, or a mnemonic such as () instructing the user which keys to press. While a BASIC program would often stop with an error at an incorrect statement, the machine language parts of a program could fail in untraceable ways. This made the correct entry of programs difficult. To counter the difficulty of keying a type-in, the MIKBUG machine code monitor for the Motorola 6800 of the late 1970s incorporated a checksum into its hexadecimal program listings. Later, some magazines developed checksum programs of their own. There were many different styles of checksum program, usually depending on the type of program being entered and on the complexity of the checksummer. Checksummers were proprietary and were generally printed in every issue of the magazine. The most basic distinction was whether the checksummer was run only once, when the program had been completely keyed in, or whether it was used interactively. The former type either read the typed-in computer code off a disk, or read it directly from memory (this type of checksummer was usually manually appended to the end of a BASIC program). The checksum program would print a checksum for each line of code. The magazine would print the correct checksums adjacent to the listing, and the user would compare the two to catch errors. More advanced checksum programs were used interactively. They would take a line of code as it was entered and immediately produce a checksum which could be compared to the printed listing. Users, however, had to enter the checksum programs themselves correctly. For example, ''Compute!'' and ''Compute!'s Gazette'' printed the BASIC listings for "The Automatic Proofreader" (to verify lines of BASIC) and "MLX" (for binary data) in each issue that carried type-in programs in these formats. Once the user had typed in "The Automatic Proofreader" correctly, he had bootstrapped his way to verifying "MLX" and other programs. Beyond the manual labor of type-ins, it was not uncommon for certain magazines to print poor quality listings, presenting the reader with nearly illegible characters (especially in the case where machine-code data was printed using extended ASCII glyphs instead of DATA statements); this typically happened when transferring the list output from the era's ubiquitous 7–8-pin dot-matrix printers directly to the printing presses – sometimes even without prettyprinting. This was particularly troublesome in listings which contained graphical characters representing control codes, used for e.g. cursor movements; such characters tended to be less legible than alphanumeric ones in the first place. Additional issues arose after the advent of BASICs that did not require line numbers as the magazine broke logical lines across physical lines due to space constraints and without the line numbers the distinction was not always apparent. Compute! even for a time used a handwritten arrow to represent a carriage return in its program listings. Of course, some errors in type-ins were the result of programmer error, and were simply bugs in the program. Magazines often issued "errata" notices to correct bad listings in subsequent issues. Other solutions existed for the tedium of typing in seemingly-endless lines of code. Freelance authors wrote most magazine type-in programs and, in the accompanying article, often provided readers a mailing address to send a small sum (US$3 was typical) to buy the program on disk or tape. By the mid-1980s, recognising this demand from readers, many US-published magazines offered all of each issue's type-ins on an optional disk, often with a bonus program or two. Some of these disks became electronic publications in their own right, outlasting their parent magazine as happened with Loadstar. Some UK magazines occasionally offered a free Evatone that played on a vinyl record player connected to the microcomputer's cassette input. Other input methods, such as the Cauzin Softstrip, were tried, without much success. Not all type-ins were long. ''Run'' magazine's popular "Magic" column specialized in one-liner programs for the Commodore 64. These programs were often graphic demos or meant to illustrate a technical quirk of the computer's architecture; the text accompanying the graphics demo programs would avoid explicitly describing the resultant image, enticing the reader to type it in. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Type-in program」の詳細全文を読む スポンサード リンク
|